Electronic design automation (EDA) has long been used to design electronic hardware such as integrated circuits. Increasingly, however, new designs have both a hardware component and a software component. For instance, an “embedded” system often includes a special-purpose hardware component that is installed in a general-purpose computer system. A software component is developed to execute on one or more processors in the computer system to allow the computer system to interact with the installed hardware component.
One familiar example of an embedded system is a “software” modem. A software modem uses the processing power of a computer system to process data traffic. A software modem only needs enough special-purpose hardware to pass data back and forth between the computer system and a telephone network. As with most embedded systems, the special-purpose hardware can be significantly simplified compared to a typical hardware device designed for the same purpose, usually resulting in smaller components and a lower price point.
Although there are numerous advantages to embedded systems, designing hardware and software components to work together is no trivial matter. Ideally, hardware is simulated and verified before a physical prototype is produced. A logic simulator works well for simulating hardware, but does not work well for simulating software execution in hardware. Under most circumstances, even the fastest logic simulators can only simulate execution of a few software instructions every second. Given that a processor may execute hundreds of thousands or even millions of instructions per second, simulating software execution using a logic simulator is often simply too slow to be useful.
An instruction set simulator (ISS) is often used to simulate software execution in a known execution unit such as a particular general purpose microprocessor or a particular digital signal processor. A typical ISS can execute instructions at a speed much closer to that of a known device being simulated. An ISS, however, only simulates the behavior of software executing on a known device. That is, for a hardware/software design embedded in a computer system, an ISS can simulate a general-purpose processor executing the software, but the ISS cannot simulate the interaction between the general-purpose processor and the special-purpose hardware.
Hardware/software co-simulation often combines a logic simulator with an ISS. The logic simulator is used to simulate the hardware component and the ISS is used to simulate execution of the software component. In most embedded designs, only a small fraction of software instructions require interaction with the special-purpose hardware. In which case, by combining an ISS and a logic simulator, the majority of software instructions can be executed at high speed by the ISS. The combined simulation only needs to slow down to the speed of the logic simulator when the simulation involves interaction with the special-purpose hardware.
Other techniques can also be used to simulate software execution such as Host Code Execution where the embedded code runs on the native host machine, or abstract software executing in a dedicated software simulation environment. Similarly the hardware can exist at many different levels of abstraction.
Although hardware/software co-simulation can significantly increase the operating speed of a simulation, the two simulation environments are typically viewed from very different perspectives. For instance, the state of software is often viewed by checking the values of variables at various stages during execution in a debugger. The state of hardware is often viewed by tracing values of registers or memory locations over time. A variable in software generally does not map directly to a register or memory location in hardware. The different perspectives make it difficult to form a coherent understanding of how a hardware/software co-simulation is operating and how a hardware/software co-simulation can or should be modified.